IBIS Macromodel Task Group Meeting date: 15 July 2014 Members (asterisk for those attending): Agilent: Fangyi Rao * Radek Biernacki Altera: * David Banas ANSYS: * Dan Dvorscak Curtis Clark Avago (LSI) * Xingdong Dai Cadence Design Systems: * Ambrish Varma Brad Brim * Kumar Keshavan * Ken Willis Ericsson: Anders Ekholm Intel: Michael Mirmak Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz * Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow * Bob Ross The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - None -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - None ------------- New Discussion: BIRD 147.1 proposal from Bob Ross: - Arpad: There was an email about a .1 version of this BIRD coming out. - Bob showed BIRD 147.1_proposal3.txt - Bob: This was sent last night. - It resulted from discussions with Ambrish. - The Formats in the BIRD were complex. - We adopted a different proposal similar to Walter Katz's proposal. - Arpad: What was the reason? - Bob: I objected to the complexity of the new formats. - The BCI rules where in two different sections. - The SiSoft proposal does the same thing without new formats. - This is close to that, but simplified. - Bob described the new syntax. - Mike: This is the first instance of reserved branch names. - Will parsers have trouble? - Todd: Is this in the BCI File? - Bob: Yes. - Todd: How is this like the SiSoft proposal? - Bob: It uses parameter hierarchy in a similar way. - Ambrish: We have rules for branches on page 185. - Bob: We have reserved branches in Protocol_Specific. - Todd: But that is also a new proposal. - David: If parsers are changed to handle that will it break them? - Arpad: Can we have reserved branches in AMI today? - Todd: Nothing in Model_Specific can be reserved. - Ambrish: We can have rules specific to the BCI file. - Mike: You could have Preamble_Bit_Pattern_Repeat. - Bob showed 802.3KR_Rx.ami - Ambrish: That is not from the SiSoft proposal. - Todd: This new BIRD is not similar to the SiSoft proposal - Bob: The nesting of branches is similar. - Ambrish: Agree,this is not the SiSoft proposal. - Arpad: Does Cadence agree with these changes? - Ambrish: We thought Strings are strings and not really Bits. - We wanted to type it so models know what they are getting. - Walter: Did you say the models read the training patterns? - Ambrish: This is about Bits, not training patterns. - Arpad: When will the BIRD arrive? - Bob: Probably next week, Ambrish and I will work on it. BIRD 128: - Arpad: This is required for BIRD 147. - Radek: There should be a separate API for BCI training. - This may change existing prototypes, but we need something better. - Arpad: A new API is OK as long as it is justified. - An argument with an input flag is not good. - BCI should not be identified by InOut status. - Radek: It's not just adding a parameter to GetWave. - It's adding a functional API. - Ambrish: The change from Out to InOut can do anything, even outside of backchannel. - Todd: AMI_GetWave doesn't already have that. - BIRD 128 is a back door means to avoid changing the footprint. - The other way is to change the footprint. - Radek has a good point. - Ambrish: The change from Out to InOut should be enough. - Arpad: It doesn't change the DLL function set. - Todd: But it changes what the functions do. - Ambrish: We could have a separate InOut argument. - Arpad: It would be cleaner to have separate in and out parameters. - AMI_parameters_out is a ** pointer to pointer. - Kumar: That is a standard practice. - Todd: It is because the size of the return is not known. - Arpad: How will memory be managed? - Ambrish: A new pointer is assigned to the handle each time. - David: Overwriting seems dangerous. - Walter: The input parameter string has to be extracted and put into the output. - It's a new string created by the EDA tool. - David: Will there be a handle that both the tool and model modify? - Walter: The tool copies part of the string from the RX to pass to the TX. - Todd: The RX returns a handle, the tool has no idea how much memory has been allocated. - Walter: AMI_GetWave always allocates a new string to return, AMI_Close frees them. - Radek: What if multiple copies of a TX are running? - Kumar: Memory will never be overwritten. - Walter: We handle that today. - Each DLL instance has it's own memory space. - They have to be re-entrant. - Mike: If GetWave is called 10,000 times are the strings all freed in AMI_Close? - Walter: I would free each one on the next call to GetWave - Mike: Then we need to specify that each returned string is invalid after the next GetWave call. - Arpad: We agreed last week that BIRD 147 should be self contained. - Walter: I want BIRD 128 to be available for other purposes. - Arpad: I don't mind keeping them separate. - There were no objections. - Mike: Does this change a pointer argument to a pointer to pointer? - Kumar: It is already pointer to pointer. - Radek: Does this conflict with the rule about passing at least a root name? - Walter: That is for AMI_Init. - We need some rules here about what the string contains. - It should have a root with the name of the BCI file. - That allows the BCI and model root names to be mixed together. - Kumar: Or BCI could be a branch. - Then other things could be passed in the future. - Walter: All of this has to be very well documented. - Arpad: Walter can you look into this? - Walter: No, the authors have to do it. ------------- Next meeting: 29 Jul 2014 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives